[GitHub]secrets.GITHUB_TOKENで実行できる権限について簡単ながらマッピングしてみた

はじめに

Workflow内でREST APIをsecrets.GITHUB_TOKENと共に実行していたところ、Resource not accessible by integration というメッセージに遭遇しました。権限がないということです。

APIを実行する場合に渡すTokenとしては

• secrets.GITHUB_TOKEN
• Personal Access Token

の2つと、GitHub App tokenがあります。これはGitHub Appを元にTokenを生成するというものです。

権限のスコープ面からみると以下の通り。

-	メリット	デメリット
secrets.GITHUB_TOKEN	発行の手間がいらない	権限が狭い
Personal Access Token	強い権限を設定できる	個人に依存する
GitHub App Token	Organization管理にできる	作成の手間がかかる

できるならsecrets.GITHUB_TOKENで済ませてしまいたいと思いつつ、何ができるのかというのが案外判りづらいものです。一応公式ドキュメントに記載はありますが、実行しようとしているAPIがそれに含まれているのか、正直なところ確認し辛いものがあります。

公式ドキュメントを参照する形となりますが、secrets.GITHUB_TOKENにて何ができて何ができないのかを列挙してみました。

secrets.GITHUB_TOKENのRead/Write

元にしたのは以下のドキュメントです。

• Permissions required for GitHub Apps
• Permissions for the GITHUB_TOKEN

range	read	write
metadata	○	-
actions	○	○
administration	-	-
blocking	-	-
checks	○	○
contents	○	○
deployments	○	○
emails	-	-
followers	-	-
gpg keys	-	-
issues	○	○
(ssh)keys	-	-
members	-	-
organization administration	-	-
organization hooks	-	-
organization projects	-	-
organization user blocking	-	-
pages	-	-
pull requests	○	○
repository hooks	-	-
repository projects	○	○
secrets	-	-
security events	-	-
self-hosted runners	-	-
single file	-	-
starring	-	-
statuses	○	○
team discussions	-	-

直ぐに確認できるようにリンクもつけています。各分類に含まれるパスが本当に多種多様だったため、詳細については割愛しています。万が一権限がなくて困った時はAdministrationを見ると、載っている確率が高いかもしれません。

○がついていない分類のAPIについては、Personal Access Tokenか、GitHub App Tokenが必要になります。

あとがき

2つのページを単純にマッピングしたといえばそれだけなのですが、案外マッピングするだけで解決するような詰まりが多かったため書き出してみました。

secrets.GITHUB_TOKENが何を網羅しているのかよく分かることと、Tokenの発行手続きなしで出来る操作というのは結構限定されるのだなと感じました。行き詰まった時にはまずはAPIのパスから権限があるのかどうかを辿ってみることをおすすめします。

参考リンク

• Permissions required for GitHub Apps
• Permissions for the GITHUB_TOKEN
• GitHub App token